Optimization of handover procedures in GPRS

ABSTRACT

The present invention discloses a method related to Attach procedures and Routing Area Update (RAU) procedures in packet switched cellular networks, in particular GPRS and UMTS networks. When an MS roams from a routing area covered by several SGSNs in an SGSN pool into a routing area covered by one SGSN (new SGSN) outside the pool, the roaming request will be sent from the new SGSN to a default SGSN, which for the new SGSN is believed to be the old SGSN. The default SGSN will, unless it itself is the old SGSN, relay the roaming request to the SGSN (old SGSN) previously serving the MS. To avoid that the default SGSN has to monitor for a response of the request, and thereby occupying resources in the default SGSN, the default SGSN inserts (or when possible, leave unchanged) the address of the new SGSN in the request. The response of the request will therefore be transmitted directly from the old SGSN to the new SGSN and not via the default SGSN as described in the existing technical specifications.

FIELD OF THE INVENTION

The present invention is related to Attach procedures and Routing AreaUpdate (RAU) procedures in packet switched cellular networks whereinseveral service nodes are connected to the same radio network. Theinvention will be described in the terminology of the UMTS and GPRSnetworks, well known for a person skilled in the art, and referenceswill be made to the 3GPP (3^(rd) Generation Partnership Project)Technical Specification 29.060 and 23.060.

BACKGROUND OF THE INVENTION

A packet switched cellular network such as GPRS or UMTS, comprisesseveral nodes handling traffic flow and signalling within and in and outof the network. One such node is the SGSN node similar to thefunctionality of MSC/VLR of GSM. An SGSN is responsible for detectingMSs in its geographical area, registering them and keeping track oftheir movements within the routing area.

Until now, a radio network node is connected towards one and only oneSGSN, as shown in FIG. 1. A radio network node is either an RNC (RadioNetwork Controller) or a BSC (Base Station Controller).

3GPP (3^(rd) Generation Partnership Project), which is a standardisationbody for 3rd generation mobile systems, is for the time being developinga concept where a radio network node is allowed to be connected towardsseveral SGSNs, as shown in FIG. 2. The idea is to place several SGSNs ina pool, and that all of them cover the same geographical area, whichthen can be bigger than the area previously covered by one SGSN. As longas an MS is located within the pool area, the MS will be attached to thesame SGSN. This has several advantages, e.g. better load sharing betweenSGSNs, reduced signalling in the core network, improved serviceperformance, better scalability and easier upgrade of the nodes. Also,it opens up for several operators to share the radio network, or partsof it, while still having separate SGSNs. This is especially useful foroperators having a 2G (2^(nd) Generation) network, but who did notreceive licenses for a 3G (3^(rd) Generation) network, or vice versa.The sharing of radio network is also useful for operators who want tocut costs.

The dotted lines in FIG. 2 shows what is new with the pool concept, i.e.that an RNC or a BSC can be connected to two or more SGSNs.

When an MS is getting attached to an SGSN, the SGSN will allocate aP-TMSI (Packet-Temporary Mobile Subscriber Identity) value to the MS. Ina pool concept, each of the SGSNs within the pool will have their ownunique range of P-TMSI values. If the value range of each of the SGSNsis given to (known by) the surrounding nodes (BSCs, RNCs or otherSGSNs), then these surrounding nodes will know to which of the SGSNs theMS is (or was) attached.

In some cases, however, the surrounding nodes will not know the P-TMSIranges of each of the SGSNs in a pool. One example of this is when an MSroams into an area covered by an SGSN that is not aware of the pool. Inthis case, the new SGSN cannot uniquely identify the old SGSN to whichthe MS was attached. Another example is when the configuration effort isminimised so that the nodes outside an SGSN pool do not know about theinternal structure of the SGSN pool. The solution to this problem isthat one of the SGSNs in a pool, referred to as the default SGSN, willbe appointed as a representative for the routing area covered by thepool. A new SGSN outside the mentioned routing area will look at the oldRouting Area id of the MS in the received request (routing area updateor attach), as usual, to determine which SGSN to contact. The defaultSGSN will be associated with that routing area id, and the new SGSN willtherefore send a request to the default SGSN without being aware of thepool. The default SGSN will know the P-TMSI ranges of each of the SGSNswithin the pool. Thus, the default SGSN can look at the received P-TMSIparameter, or the TLLI (Temporary Logical Link Identity) parameter thatis based on the P-TMSI parameter if this is received instead, andforward the message to the correct SGSN. This aspect is alreadydiscussed within 3GPP (3^(rd) Generation Partnership Project), and it isshown in FIG. 3 for the Attach procedure and in FIG. 4 for the RoutingArea Update procedure. FIG. 3 and FIG. 4 show how the beginning of thesetwo procedures must be done when using the existing procedures definedin 3GPP TS (Technical Specification) 29.060. Said TS defines themessages that are sent between two SGSNs, and the messages that are sentbetween an SGSN and a GGSN (Gateway GPRS Support Node, where GPRS standsfor General Packet Radio Service).

Referring to FIG. 3, in step 1, the MS that previously was located in anSGSN pool area covered by the Default SGSN and the Old SGSN, roams intoan area covered by the New SGSN, and sends an Attach Request message tothe New SGSN. The New SGSN looks at the received ‘old Routing Area’ tofind which SGSN to contact, and in this case it is the Default SGSN.

In step 2, the New SGSN sends an Identification Request message to theDefault SGSN. The Default SGSN looks at the old P-TMSI to determinewhich SGSN within the pool handled the MS before it was roaming. TheP-TMSI in this example belongs to the Old SGSN.

In step 3, the Default SGSN relays the Identification Request message tothe Old SGSN. The Default SGSN must also keep information on from whichSGSN it received the Identification Request message (i.e. the New SGSN)to be able to send the response to the correct SGSN.

In step 4, the Old SGSN returns an Identification Response message tothe Default SGSN.

In step 5, the Default SGSN relays the Identification Response messageto the New SGSN, and this is based on the information stored in step 3.

Now referring to FIG. 4, in step 1, the MS that previously was locatedin an SGSN pool area covered by the Default SGSN and the Old SGSN, roamsinto an area covered by the New SGSN, and sends a Routing Area UpdateRequest message to the New SGSN. The New SGSN looks at the received ‘oldRouting Area’ to find which SGSN to contact, and in this example it isthe Default SGSN.

In step 2, the New SGSN sends an SGSN Context Request message to theDefault SGSN. The Default SGSN looks at the old P-TMSI, or the TLLI(Temporary Logical Link Identity) parameter, which is based on theP-TMSI parameter if this is received instead, to determine which SGSNwithin the pool handled the MS before it was roaming. The P-TMSI, or theTLLI, in this example belongs to the Old SGSN.

In step 3, the Default SGSN relays the SGSN Context Request message tothe Old SGSN. Since the Default SGSN must monitor the response for thismessage in the way the GTP (GPRS Tunnelling Protocol) protocol isdefined today, the Default SGSN must change the ‘IP address’ and the‘TEID’ (Tunnel Endpoint IDentifier) for where it wants to receive theresponse message. The Default SGSN must also keep information on fromwhich SGSN it received the SGSN Context Request message (i.e. the NewSGSN) to be able to send the response to the correct SGSN.

In step 4, the Old SGSN returns an SGSN Context Response message to theDefault SGSN.

In step 5, the Default SGSN relays the SGSN Context Response message tothe New SGSN, and this is based on the information stored in step 3.

The problem with the sequences in FIG. 3 and FIG. 4 is that theIdentification Response message and the SGSN Context Response messagemust be sent through the Default SGSN, as shown in step 4. This meansthat the Default SGSN must keep some state information for this MS aswell as some information on which SGSN it received the IdentificationRequest message or SGSN Context Request message from, as described instep 3 for FIG. 3 and FIG. 4. This means that unnecessary resources areoccupied and unnecessary processor load is generated in the DefaultSGSN. Also, this will slightly increase the time needed to perform ahandover.

The concept of placing several SGSNs in a pool is not previously knownin GSM (Global System for Mobile Communication). The above-describedhandover problems are new problems that appeared in the currentstandardisation of the pool concept within 3GPP, and therefore there areno known solutions to the problem.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide an arrangement thateliminates the drawbacks described above. The features defined in theclaims enclosed characterize this method.

The present invention relates to a method and system within a packetswitched cellular network including at least one pool of first servicenodes being able to service terminals in the same area and at least onesecond service node not included in the pool of said first servicenodes, wherein the terminals are each allocated one temporarily identityby each of said at least one second service node, and wherein theterminals are each allocated one temporary identity from an identityrange unique for said pool of said first service nodes, wherein thepresent invention, in response to a new service node within said atleast one second service node receiving a first request message from oneof the terminals previously served by an old service node associatedwith the pool of said first service nodes, sending a second requestmessage from the new service node to a default service node alsoassociated with the pool of said first service nodes and including atemporary identify of the terminal allocated by the old service node. Inaccordance with the teachings of the present invention, the defaultservice node then identifies the old service node by means of thetemporary identity included in the received second request messagewherein an address of the new serving node is included in the secondrequest message and relayed to the old service node. To return aresponse message to the new service node, the old service node thenaddresses the response message by means of the address included in thereceived second request message.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to make the invention more readily understandable, thediscussion that follows will refer to the accompanying drawings.

FIG. 1 shows the relationship between the nodes in a GPRS/UMTS networkaccording to common practice,

FIG. 2 shows the relationship between the nodes in a GPRS/UMTS networkaccording to the pool concept introduced in a new release of the 3GPPstandard (Release 5),

FIG. 3 shows an Attach Procedure when an MS attaches a standalone SGSN(or an SGSN in another pool) after having been attached to a SGSN in apool,

FIG. 4 shows a Routing Area Procedure when an MS roams from an SGSN in apool to a standalone SGSN (or an SGSN in another pool),

FIG. 5 shows an Attach Procedure according to the present invention whenan MS attaches a standalone SGSN (or an SGSN in another pool) afterhaving been attached to an SGSN in a pool,

FIG. 6 shows a Routing Area Procedure according to the present inventionwhen an MS roams from an SGSN in a pool to a standalone SGSN (or an SGSNin another pool).

DESCRIPTION OF THE PRESENT INVENTION

Two embodiments of the present invention will now be described withreference to FIG. 5 and FIG. 6, respectively. The first embodimentdescribes two alternative solutions addressing an attach procedure,while the second embodiment describes a solution for the routing areaupdate procedure.

In step 1 of FIG. 5, the MS that previously was located in an SGSN poolarea covered by at least the Default SGSN and the Old SGSN, roams intoan area outside the pool covered by the New SGSN, and sends an AttachRequest message to the New SGSN. The New SGSN looks at the received ‘oldRouting Area’ to find which SGSN to contact, and in this example it isthe Default SGSN.

In step 2, the New SGSN sends an Identification Request message to theDefault SGSN. The Default SGSN looks at the old P-TMSI to determinewhich SGSN within the pool handled the MS before it was roaming. TheP-TMSI in this example belongs to the Old SGSN.

In step 3, the Default SGSN relays the Identification Request message tothe Old SGSN. This message should now include the address of the NewSGSN, and the Default SGSN should not monitor the response message fromthe Old SGSN.

In step 4, the Old SGSN returns an Identification Response messagedirectly to the New SGSN.

According to the first embodiment of the present invention, the newfunctionality for this attached sequence is as follows:

The Default SGSN should include the address of the New SGSN whenforwarding the Identification Request message to the Old SGSN.

This may be done in two ways. One alternative is that the Default SGSNleaves the ‘Source IP Address’ from the IP (Internet Protocol) layer ofthe Identification Request message unchanged when relaying theIdentification Request message to the old SGSN. Normally, according tothe Internet Protocol, this address would have been the address of thesender, i.e. the default SGSN, but by instructing the default SGSN toleave the address of the new SGSN in the ‘Source IP Address’ fieldunchanged when relaying the Identification Request message to the oldSGSN, the old SGSN would think that the message was transmitted directlyfrom the new SGSN, and return an Identification Response to the newSGSN.

A second and preferred alternative is that the Default SGSN inserts the‘Source IP Address’ from the IP layer (or ‘SGSN Address’) as a parameterin the GTP (GPRS Tunnelling Protocol) part of the Identification Requestmessage. The GTP is described in 3GGP TS 29.060, and is a protocoldescribing signalling messages sent between SGSNs and signallingmessages sent between an SGSN and a GGSN. Now, if the Old SGSN receivesthe ‘Source IP Address’ (or ‘SGSN Address’) as a parameter in the GTPpart of the Identification Request message, this IP address shall thenbe used when sending the Identification Response message. Consequently,in this alternative, the Old SGSN should not use the ‘Source IP Address’from the IP layer when sending the Identification Response message, eventhough this is the normal behaviour.

In both cases, the Default SGSN does not have to monitor theIdentification Response message from the Old SGSN. (The reason for whyan SGSN sending an Identification Request message wants to monitor theIdentification Response message is in case re-transmission of theIdentification Request message is needed). Also, there is no need forthe default SGSN to store any state information about the MS or theidentity of the new SGSN.

FIG. 6 shows the message flow according to the second embodiment of thepresent invention. In step 1, the MS that previously was located in anSGSN pool area covered by the Default SGSN and the Old SGSN, roams intoan area covered by the New SGSN, and sends a Routing Area Update Requestmessage to the New SGSN. The New SGSN looks at the received ‘old RoutingArea’ to find which SGSN to contact, and in this example it is theDefault SGSN.

In step 2, the New SGSN sends an SGSN Context Request message to theDefault SGSN. The Default SGSN looks at the old P-TMSI, or the TLLIparameter, which is based on the P-TMSI parameter if this is receivedinstead, to determine which SGSN within the pool handled the MS beforeit was roaming. The P-TMSI, or TLLI, in this example belongs to the OldSGSN.

In step 3, the Default SGSN relays the SGSN Context Request message tothe Old SGSN. This message should include the address of the New SGSN(both ‘TEID’ and ‘SGSN IP Address’) within the GTP part of the message,and this is already possible in the existing message.

In step 4, the Old SGSN returns an SGSN Context Response messagedirectly to the New SGSN.

According to the second embodiment of the present invention, the newfunctionality for this routing area update sequence is as follows:

The Default SGSN should include the address of the New SGSN (both ‘TEID’and ‘SGSN IP Address’) when relaying the SGSN Context Request message tothe Old SGSN in the GTP part of the SGSN Context Request message. Thismeans that the Default SGSN should not change this part of the messagewhen receiving it from the New SGSN.

The result also of this embodiment is that The Default SGSN does nothave to monitor the SGSN Context Response message from the Old SGSN, andthere will be no need for the default SGSN to store any stateinformation about the MS or the identity of the new SGSN.

The present invention gives the opportunity of the Old SGSN to send theIdentification Response message and the SGSN Context Response messagedirectly to the New SGSN, as shown in FIG. 5 and in FIG. 6, so thatresources are not unnecessarily occupied in the Default SGSN, and aminimum of processing capacity is required. Also, this will slightlydecrease the time needed to perform a handover, as one signalling stepwill be avoided

The present invention is applicable for both GSM (Global System forMobile Communication) GPRS and UMTS (Universal Mobile TelecommunicationSystem) GPRS.

1. Method in a packet switched cellular network including at least onepool of first service nodes operative to serve terminals in a firstservice area and at least one second service node not included in thepool of said first service nodes, wherein each terminal within saidfirst service area is allocated a temporary identity from an identityrange unique for said pool of first service nodes, said methodcomprising the steps of: a) in response to a new service node associatedwith said at least one second service node receiving a first requestmessage from one of the terminals previously served by an old servicenode associated with the pool of said first service nodes, when saidterminal roams from said first service area into an area serviced bysaid second service node, sending a second request message from the newservice node to a default service node also associated with the pool ofsaid first service nodes, said second request message including saidtemporary identity of the terminal allocated by the old service node; b)in the default service node, identifying the old service node by meansof the temporary identity included in the received second requestmessage; c) adding, by said default service node, an address of the newserving node to the second request message and relaying it to the oldservice node; and, d) in the old service node, returning a responsemessage directly to the new service node by addressing the responsemessage to the address of the new service node added by the defaultservice node to the received second request message.
 2. Method accordingto claim 1, wherein that the packet switched cellular network is a GPRSnetwork and the serving nodes are SGSN nodes.
 3. Method according toclaim 2, wherein that the first request message is an Attach Request,the second request message is an Identification Request and the responsemessage is an Identification Response.
 4. Method according to claim 2,wherein that the first request message is a Routing Area Update Request,the second request message is an SGSN Context Request and the responsemessage is an SGSN Context Response.
 5. Method according to claim 2wherein that the temporary identities are P-TMSIs.
 6. Method accordingto claim 2 wherein that the temporary identities are TLLIs.
 7. Methodaccording to claim 2 wherein that the inclusion of the address of thenew serving node in the second request message in step c) is carriedthrough in the default serving node by leaving the source IP Address ofthe new serving node in the second request message unchanged whenrelaying the second request message to the old serving node.
 8. Methodaccording to claim 2 wherein that the inclusion of the address of thenew serving node in the second request message in step c) is carriedthrough in the default serving node by inserting the Source IP Addressfrom the IP layer of the received second request message as a parameterin the GTP part of the second request message.
 9. Method according toclaim 8, wherein that in case the inclusion of the address of the newserving node in the second request message in step c) is carried throughby inserting a Source IP Address as a parameter in the GTP part of thesecond request message, the old service node uses this Source IP Addressas the destination IP address of the response message mentioned in stepd).
 10. Method according to claim 7 wherein that the second requestmessage is an Identification Request message, and the response messageis an Identification Response message.
 11. Method according to claim 2wherein that the inclusion of the address of the new serving node in thesecond request message in step c) is carried through in the defaultserving node by leaving unchanged the TEID and the SGSN IP Address ofthe new SGSN in the GTP part of the second request message.
 12. Methodaccording to claim 11, wherein that the second request message is anSGSN Context Request message.
 13. Method according to claim 2 whereinthat the default service node does not supervise the response messagethat the old service node will return as a result of the second requestmessage being relayed in step c).